GCPUG Beginners Tokyo 13 feat. GCPのセキュリティに参加してきました #gcpug

中山順博

2019.02.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

中山（順）です

最近、セキュリティネタにアンテナ張りがちです。

今回、セキュリティがテーマということで参加させていただき、内容を整理してみました。

この投稿では、発表内容＋後日調べた内容（主に公式ドキュメントへのリンク）という形でまとめてみました。

勉強会概要

募集ページはこちらです。

GCPUG Beginners Tokyo #13 feat. GCPのセキュリティ

GCPのユーザーグループの概要はこちらです。

GCPUG

GCPのセキュリティ

登壇者は、Google Cloud Japan カスタマーエンジニア（いわゆるプリセールス）の森永さんです。

発表時、Google SlideのQ&Aセッション機能を使って質問を随時受け付けていました。

ユーザーからの質問を受け付けて表示する

当日は以下の概要に沿ってGCPのセキュリティについて解説頂きました。

Googleのセキュリティの取り組み
GCPを支えるセキュリティ
GCPでできるセキュリティ対策

なお、資料公開は行わないとのことです。

これ以降の記述は筆者が聴講しながらおこなったメモをベースにしたもので、聞き間違いや誤解が含まれる可能性があります。

公式ドキュメントなどは可能な範囲で確認しましたが、正確性を保証することはできません。

サービスの仕様／Google社のステートメント・規約等は公式サイトを参照してください。

1．Googleのセキュリティの取り組み

Google自体のセキュリティに関する取り組みの紹介
具体例
BEYONDCORP 企業セキュリティに対する新しいアプローチ
Project Zero
Multi Factor Authentication
Titan Security Key
フィッシング対策
Beyond Corp
実際の会社じゃない
概念
"Zero Trust"
従来の考え方は「境界」でのアクセス制御が主体
VPNゲートウェイなどで認証
社内は安全＝従来の考え方
社内NWは安全という暗黙の前提
新たな考え方
社内NWも社外NWも危ない、という前提で設計 (Zero Trust)
エンドポイントでユーザー認証とデバイス認証を組み合わせて保護
Googleでは、業務で公衆無線LANの利用は禁止されてない
CLOUD IDENTITY-AWARE PROXYをサービスとして公開している
Googleはたくさんの攻撃を受けてきた
その経験を踏まえたセキュリティの取り組みを実施
Webサイト
Chrome
Android
Gmail
体制
多数のセキュリティエンジニア
Project Zero
Googleのサービス等（Googleのサービスや製品に限らない）の脆弱性を特定／分析するチーム
実績
Spectre, Meltdown, Heartbleed など
その他、Windowsの脆弱性も多数発見
報酬プログラムもやってる

2．GCPを支えるセキュリティ

よく聞かれること
「Googleってユーザーのデータ見るんじゃないの？」
Google Cloudにおいては違う（後述）
Principal
Google Cloudにおいては、セキュリティは最優先事項
Google（個人向けのサービス）とGoogle Cloud（法人向けのサービス）は「別物」
規約が違うのでよく確認してほしい。
B2C向けのサービスにおいてはデータを利用するケースはあるが、個人情報の取り扱いは慎重に行われている。（匿名化など）
Google CloudはGCPだけではない
GCP以外のサービス
G Suite
Cloud Identity
Chrome
Android
認証やデバイス、エンドポイントも含まれる
セキュリティは多層防御が基本
物理／インフラのレイヤーにおいても多層的に防御している
データセンターの立地
データセンターへのアクセス権
その他
詳しくはこちら（信頼できるインフラストラクチャ）
方針
基本的に自分で作る
ハードウェアも作ってる
チップ、サーバー、ストレージ、ネットワーク、データセンター、などなど
不要なコンポーネント = 脆弱性などのリスク
Reduce "Vendor in the Middle" Risk
Googleのグローバルネットワーク
大阪リージョンも提供開始予定
データは「デフォルトで」暗号化している
データを分割する
暗号化のための鍵も暗号化
保存先も分散
詳細はこちら（Encryption at Rest in Google Cloud Platform）
大規模なバッチ適用を利用者が気づくことなく
Spectre, Meltdownへの対応は公表前に対策してた
Project Zeroの成果
Live Migrationを利用してダウンタイムなしで対処した
責任共有モデル
IaaS > SaaS で責任を負う範囲は違う
「クラウドセキュリティの責任は、お客様と Google で共有」
サービスによって責任分解点が違う
一般的なセキュリティ対策、考慮するポイント
インフラ、ネットワーク、データ、アプリケーションなどの各レイヤー
エンドポイント、認証
コンプラインス・ガバナンス
監視や運用
各種認証を取得
ISO27001などのグローバルなの
各国の規制に対応した認証の取得やガイドラインに対応するためのチェックリストなどのリソースを提供
日本の各種ガイドラインへの対応状況
FISC
第9版に対応したリファレンスに対応している
3省4ガイドライン（医療情報システム）
総務省、経産省、厚生労働省
CSV
製薬会社むけのガイドライン
NISC
内閣サイバーセキュリティセンター

3．GCPでできるセキュリティ対策

ここからはGCPの具体的なサービス内容の紹介となります。

権限管理

GCPのリソースは階層的に管理される
Organization
最上位の概念
フォルダ
4層まで作れる
組織図の通りに作るのではなく、権限委譲したい内容に応じて作るべき
権限は継承される
プロジェクト
個人でGCPのアカウントを作ると、プロジェクトが1つできる
配下にリソースが作成される
Billingをプロジェクトに紐付ける
リソース
VMなど
詳しくはこちら（Resource Hierarchy）
組織ポリシー
組織、フォルダー、プロジェクトに対するポリシーの定義
継承される
許可も出来るし、制限も出来る
制限の例
GCE:外部IPの付与を許可するかしないか、など
IAM:参加できるドメイン（ユーザーのメールアドレス）を制限、など
Organization Policy Constraints
IAM
IDの管理と権限の付与
権限付与の対象
Googleアカウント
Googleグループ
サービスアカウント
他
詳しくはこちら（Overview）
権限の付与の仕方
ユーザーはグループに所属
グループにロールを付与
ロールにプロジェクトへのアクセス権を定義
サービスアカウント
GCPの各サービス
サービスに対して権限を委譲できる
詳しくはこちら（リソース階層を使用したアクセス制御）
許可／拒否するアクションの定義
命名規則
サービス名 + リソース + 動詞 (Create, Get, etc)
APIとは1:1
例
compute.images.get
GUI上での単一操作で複数のAPIをコールするので、厳密過ぎる権限制御は大変
定義済みのロール
Primitive roles
管理者（IAMの管理権限を含む）
編集者（IAMの管理権限を除く）
閲覧者
サービス毎の定義済みロール (Predefined roles)
管理者
編集者
閲覧者
その他（ストレージ管理者など。定義済みロールの粒度はサービスによって異なる）
カスタムで役割を定義することもできる
最小権限が理想ではある
設計によっては運用大変なのでやるなら覚悟を
詳しくはこちら（Understanding Roles）
Tips
プロジェクトをうまく分割すると便利
プロジェクトを消すとリソース消せる
開発環境を一括削除できる
IAM Condition
Private Beta
時刻やソースIPなどを利用してアクセス制御できる
将来的には、デバイスのOSが最新か、などクライアントのコンテキストを評価できるようになるらしい
詳しくはこちら（Overview of Cloud IAM Conditions）

データ漏洩を防ぎたい

クラウドになって、「境界を守ればよい」って状況ではなくなった
マネージドサービスからのデータ漏洩のリスク
リスクの例
過剰な権限の付与（例：他のプロジェクトににデータをコピー）
クレデンシャルの漏洩
雑な設計や運用によってリスクは増える
VPC Service Control
境界線を定義できるサービス
境界線の内外からのアクセスを制限できる
内側から外側
外側から内側
ユーザーに権限があってもアクセスを制限できる（VPC Service Controlが優先される）
様々な設計パターン
複数のプロジェクトを1つの境界にまとめることもできる
オンプレのネットワークやリソースも境界に含めることができる
クライアントのコンテキストに応じた制御も可能
境界をブリッジすることも可能
詳細はこちら（Overview of VPC Service Controls）
設計が難しいので、利用するかどうかは慎重に検討を
個人情報などの機密性の高いデータの保護に限定するなど、ピンポイントでの利用はオススメ
仮想マシンの保護は従来通り、BigQueryなどのAPIベースのサービスをVPC Service Controlで制御するなどの使い分け
その他の対策
DLP（スキャン、匿名化、削除）、PII、保存する前にデータを処理

監査のためのログを管理したい

Cloud Audit Logging
GCPのアクティビティ、データへのアクセス
エクスポートや検索も可能
記録されるログの種類
管理アクティビティ
リソースの作成や削除など　課金なし　保持期間400日　長期保存はエクスポート　デフォルト有効
システムイベントログ
GCEで実行されたイベント（Live Migrationの実行履歴も含まれる）　課金なし　保持期間400日　長期保存はエクスポート　デフォルト有効
データアクセスログ
デフォルトオフ（BigQueryを除く）、保持期間30日　サービス毎に有効化できる　課金に注意
詳細はこちら（Cloud Audit Logging）
GCSやBigQuery, Pub/Subへのエクスポートをサポート
ログの集約エクスポートも可能
組織全体・特定フォルダなどの単位でログをエクスポート
詳しくはこちら（Aggregated Exports）

DoS/DDoS対策

トレンド
数Tbpsクラスの攻撃が発生するようになっている
「YouTubeを50万人同時視聴、HD画質」のレベル
防御手段
L3/L4　LB/CDNにおけるDDoS攻撃の緩和
Cloud Armor（アプリケーションレイヤーの脆弱性対策 / WAF）
リリース前の脆弱性診断
Idenity aware Proxy
クライアントのコンテキストに基づいて制御
GCPのパートナーソリューション

まとめ

Googleのサービスで利用しているインフラと同じレベルのセキュリティを得られる
数多くのセキュリティサービスを利用できる

まとめ／感想

普段は触れないサービスや技術に触れるのっていいですよね。新鮮です。個人的に興味深かったサービス／機能としては、認可の際にクライアントのコンテキストを評価できる点です（現在はLimited Preview）。ここまでできるようになるとセキュリティリスクはさらに軽減できそうですね。この辺はChromeやAndroidを作っているGoogleならではって感じですね。今後もGCPに限らず、幅広くいろんなサービスに触れていきたいと思います。

また、AWSとの違いってどんなところだろうって観点でも聞いていましたが、概要レベルでは大きな差異はなさそうって印象を持ちました。もちろん、設計思想や抽象化の仕方、そのほか細かい違い（機能の差／特定のワークロードにおける性能差など）はいろいろあると思います。事業会社のエンジニアの方などはミッションが明確ですので（私からすると）ちょっとした機能／性能の違いを大きな違いとして認識する場合はあると思います。

ちなみに、GCPの公式ドキュメントには以下のような比較ページがあります。

Google Cloud Platform for AWS Professionals

クラウドの検討を実施する際、一番最初に比較表を作ろうとするケースが稀によくありますが、 AWSやGCP「全体」を比較しても有意な差を見つけることは難しいと考えています。それは、差が少ないということでもありますが、いずれも機能が膨大ですべての比較が困難だからです。検討にあっては、以下のような順序で考えるべきではないかと考えています。（当たり前だと思いますが）